UID2-7797 Allow the ACI-injected managed-identity env vars in the CCE policy - #2720

Problem

Azure ACI has begun injecting three managed-identity environment variables into confidential containers: APP_IDENTITY_ENDPOINT, IDENTITY_ENDPOINT and IMDS_ENDPOINT.

The generated CCE policy has no env_rules matching them, and allow_environment_variable_dropping is set to false on the very next line, so an unmatched env var is a hard failure at container creation. The operator never starts, so it never attests and SKR never releases the encryption key.

This affects every Azure private operator as ACI rolls the change through each region. Two are already confirmed down: LinkedIn (UID2-7797) and Symitri (UID2-7806).

Changes

1. Allow the three injected vars — explicit re2 env_rules on both the uid2-operator and skr containers.

allow_environment_variable_dropping deliberately stays false, preserving the intent of 06e664c ("Prevent the adding of env variables to Azure operator") — the operator runs in the partner's own Azure subscription, so an unexpected env var should fail loudly rather than be silently discarded.

Relaxing the flag instead would not have been sufficient anyway: skr needs IDENTITY_ENDPOINT / IMDS_ENDPOINT to fetch the managed-identity token for key release, so dropping them silently breaks attestation a different way.

2. Assert the edits actually applied — fail the build if they did not.

Both seds are anchored on the exact JSON shape az confcom emits, and the confcom version is not pinned in this script. If a future version reorders, renames or drops the rules the seds match on, they no-op without error and we publish a policy that cannot attest: the same outage, but silent.

That is not hypothetical for the next release. SKR moved 11 minor versions (2.3 → 2.14) in b4c06f5, and the env_rules sed has only been verified against a policy built with 2.3. The assertion checks each of the three vars has exactly two rules (one per container) and that the dropping flag is false.

Verification

Ran the full az confcom acipolicygen pipeline on a throwaway Azure VM (az 2.90.0, confcom 2.1.0) against the pristine operator.json from the 5.62.24-r2 release:

• confcom 2.1.0 emits zero occurrences of the three vars — its built-in ACI-injected allowlist is still stale, so the sed is required rather than a confcom bump.
• The resulting containers block is byte-identical (sha256 da0c25fa…) to a minimal-delta policy derived independently from the currently-registered April artifact, confirming the edit adds exactly the three rules and nothing else.
• No image, layer, entrypoint, capability, mount or fragment changes.
• The new assertion passes on the fixed policy and fails on the same policy before the fix.

The resulting enclave ID 3d61a2ed55cf3c79ec961dcfb8d4d8d8b1b8277051654516f6ce4f076f0abe7e is registered in integ and prod as azure-cc-uid2-5.62.24-r2-omit-id2-extra-aci-env.

Still to do, not in this PR

• Validate against v5.70.159-r0 (the version the docs site tells partners to run). It carries SKR 2.14, and a6902e9 removed the IMAGE_NAME env var from the template, so its policy differs beyond these three rules. The new assertion will now catch it if the sed stops matching, rather than shipping quietly. Tracked on UID2-7804 / UID2-7805.
• Pin or record the az confcom version. confcom 2.1.0 emits api_version := "0.11.0" plus a rw_mount_device framework rule, where currently-registered policies are 0.10.0 — same containers block, different digest. Tracked on UID2-7804.

Ticket: UID2-7797